Columbia Kermit/kermit.zip/newsgroups/misc.20010306-20010921/000247_keithuse@synco_pator.com_Fri Jul 6 09:50:31 EDT 2001.msg

Text File | 2020-01-01 | 6KB | 141 lines

Article: 12572 of comp.protocols.kermit.misc
Path: newsmaster.cc.columbia.edu!panix!howland.erols.net!newsfeed.direct.ca!look.ca!newsfeed1.earthlink.net!newsfeed.earthlink.net!newsmaster1.prod.itd.earthlink.net!newsread1.prod.itd.earthlink.net.POSTED!not-for-mail
Newsgroups: comp.protocols.kermit.misc
From: keithuse@synco_pator.com (Keith Doyle)
Subject: Re: Any way to alter Kermit "quit" so I don't have to "kill?"
References: <h_417.5247$[e-mail]> <9i2n2o$dgn$[e-mail]>
Reply-To: keithuse@synco_pator.com (Keith Doyle)
Organization: Rexx Electronic Communications
X-Newsreader: trn 4.0-test74 (May 26, 2000)
Lines: 121
Message-ID: <ORb17.6797$[e-mail]>
Date: Fri, 06 Jul 2001 05:17:34 GMT
NNTP-Posting-Host: 207.167.89.8
X-Complaints-To: [e-mail]
X-Trace: newsread1.prod.itd.earthlink.net 994396654 207.167.89.8 (Thu, 05 Jul 2001 22:17:34 PDT)
NNTP-Posting-Date: Thu, 05 Jul 2001 22:17:34 PDT
X-Received-Date: Thu, 05 Jul 2001 22:15:20 PDT (newsmaster1.prod.itd.earthlink.net)
Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:12572


In article <9i2n2o$dgn$[e-mail]>,
Frank da Cruz <[e-mail]> wrote:
>In article <h_417.5247$[e-mail]>,
>Keith Doyle <keithuse@synco_pator.com> wrote:
>:
>: Now my original approach used lrz something like the following:
>:
>:     lrz </dev/modem >/dev/modem
>:
>: Since this doesn't hang up the line, I presume that the issue is NOT
>: "close" of the device.
>:
>Right -- it uses the open stdin/stdout file descriptors, which have
>been redirected from/to the modem.  Since the lrz program uses stdin/out,
>it never opens or closes it.


Though the shell does-- and that doesn't cause a disconnect.

Also, neither does this simple C program, run in place of the
kermit or lrz/lsz, so I'm inclined to doubt it's the close that's
responsible for the disconnect:
--------------------------------------------------------------
#include <stdio.h>
#include <fcntl.h>

main()
{
int d;
    d = open("/dev/modem",O_RDWR);
    sleep(4);
    close(d);
    exit (0);
}
--------------------------------------------------------------



>: So I tried serveral things.  I noticed that it is possible to pass in
>: an open file descriptor and have kermit use that.  But, I gathered
>: you can't just do:
>:
>:     kermit -r -i -l 0 </dev/modem
>:
>: As this is only open for input, and kermit is going to need bidirectional
>: I/O on the FD.
>:
>Did you try it?

Yes, with no success.  It never seemed to negotiate with the other end
and start the transfer.  I'll have to report back on more specific details
when I try it again...

>: So lastly, I figured ok, let's see if it really is the close of the
>: device or something *specific* kermit is doing on exit.  I manually
>: invoked kermit so that it wouldn't exit, and instead of doing a "quit"
>: after the transfer, I switched to another window and did a kill -9
>: on the kermit process.  Voila!  no disconnect occurred.
>:
>Because you killed Kermit and it couldn't close the device.  Meanwhile
>another process had it open, right?  That's why you didn't carrier drop
>or whatever.

Even on a kill of that sort, Unix does the close, I believe.
And as noted, the C test program specifically closes and that doesn't
cause a disconnect.  You can try something similar yourself, using
another kermit process itself to simulate my driver program:


1. From a unix box, Start a kermit session on a modem, and dial a system
2. escape to the command line
3. shell out
4. run my little test program on the apropriate /dev  (/dev/modem in my
   case).  Note no disconnect.

5. Remove the kermit lock file (only so you can run a second kermit on the port)
6. run a second kermit (from the original kermit shell-out) on the same /dev and
   then just do a quit.

7. Kermit will warn you there may be an active connection, and ask you if
   you still want to exit.  Your choice is to either not-exit or say yes
   you want to exit at which point it disconnects the line.  I believe if
   it just did a "close" and then an "exit" here things would be ok, but
   more is going on.


>Try the first method (-l 0) and see what happens.  If that doesn't work,
>what I'd recommend is to let Kermit handle everything -- dialing, terminal
>session, and file transfer.  That's what it's designed for.

That may be what it's designed for, but I already have an exceedingly
complex program that originally used zmodem that I'm not going to rewrite
from scratch in a specialized script language I would have to learn
special for that one purpose, when all I need is something that
implements the protocol without mucking with the connection-- I just want
to plug in a replacement protocol without rewriting the whole schmeer.
"kermit -r -i -l 0 </dev/modem" would be great if I can get it or something
like it to work-- so far I haven't had any luck getting it to transfer...


>In any case, let us know what happens and we'll see what to do next.

If there's a way to make the FD approach work, it's worth investigating
further.  I presume it should work, but there's something I must not be doing
right to set it up.  I'll try it a little more and report back more specific
on what I tried and how it acts.  Thanks for the response-- I do get the idea
that kermit in general is a far more sophisticated program than zmodem
(certainly way more robust a protocol) but I must admit I rather like the
modularity of keeping the protocol separate from the scripting...




--

Keith Doyle      <http://www.syncopator.com/carousel>
(to send me an E-letter, remove underbars in reply address)

"Simple ain't easy."  -- Thelonious Monk